Method and system for associating parameters of containers and contained objects

ABSTRACT

A system and method for establishing associative relationships between properties of a contained object and corresponding parameters of a container application. The system contemplates establishment of mutual and unilateral associative relationships, with a particular relationship being specified via a user interface created upon instantiation of the contained object. Such associative relationships may be advantageously established without modification of the code comprising the contained object. In one aspect the system facilitates implementation of selected functionality of a container application prescribed by an event script. In this context an association is created between an event arising within a contained object instantiated in a computing environment and a script associated with the container application. An event indication is generated in response to occurrence of a particular event within the contained object. In response, the event script is invoked and a sequence of script commands corresponding to the selected functionality are carried out.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continued prosecution application of applicationSer. No. 09/241,938, filed Feb. 1, 1999.

This application claims the benefit under Title 35, United States Code,§ 119(e) of U.S. provisional application No. 60/103,362 filed on Oct. 7,1998.

FIELD OF THE INVENTION

This invention relates generally to data processing systems and, moreparticularly, to a method and system for creating associations betweenparameters of a container application program and correspondingparameter of a contained object.

BACKGROUND OF THE INVENTION

The operation of a computer system is controlled by a computer programor group of programs called the operating system (“OS”). In earlyoperating systems, a computer user input text commands to the OS using acommand line interface. Later, more advanced operating systems weredeveloped which utilized a graphical user interface (“GUI”) incombination with an input device such as a mouse. In GUIs, the inputdevice controls a display cursor to allow for the selection of data andresources for application program operations. A user selects anoperation by highlighting an item or field and pressing a graphicalinput device button.

Many GUI programs are implemented in object-oriented programminglanguages, such as the C++ programming language. The display icons thatrepresent data or resources are typically representations of datastructures called objects, which encapsulate attributes and behaviors.Objects are specified by definitions, called classes, that specify theattributes and behaviors of the particular objects, which are termed“instantiations” of the class definitions. The reference Budd, T., “AnIntroduction to Object-Oriented Programming”, Addison-Wesley PublishingCo., Inc. 1991, provides an introduction to object-oriented concepts andterminology.

Object-oriented programming languages make it easier for systemprogrammers to implement the GUI concepts of icons and lists. Forexample, if the GUI icons are represented as object-oriented programmingobjects, the GUI program can be written so that the status of the iconis continuously updated. In this way, it is relatively simple for theGUI program to be written so that the icons can be selected with thegraphical user input device and moved about on the computer systemdisplay as desired.

With the advent of object-oriented GUIs also came object orienteddeveloping environments. Such development environments are computerprograms or groups of computer programs that allow a software developerto create object oriented programs. Object-oriented developmentenvironments typically have a palette of objects with which thedeveloper builds an application. Each object on this palette isdifferent and serves as a template for the developer. A palette object'sattribute settings are the default settings for that object. To use anobject on the palette, the developer copies the object and places thecopy on the application. The copied or “derived” object has the sameattribute settings as the original palette object.

Efforts have been made to establish a common method of communicationbetween objects instantiated within a given operating systemenvironment. For example, Microsoft Corporation has established acertain protocol, known as the Component Object Model, which governs theinteraction between software objects within the Microsoft Windowsoperating environment. COM provides a standard framework permittingobjects from different applications to share data and functions, andpermits a given application program (“container application”) to containmultiple objects of different types. Recently, a format for controlobjects known as “ActiveX” has been established to take advantage of theCOM protocol. An ActiveX object behaves as a “server” relative to itscontainer application, which in turn behaves as a “client”. The COMprotocol manages, among other things, the setup and initializationnecessary for container applications to send and receive messages anddata to and from server applications.

An ActiveX control is an object which typically includes data andfunctions, and which is capable of notifying its container applicationof the occurrence of an event. In the context of an ActiveX control,stored data members are known as “properties”, functions are referred toas “methods”, and event occurrences are denoted as “events”. Propertiescan be read from, and written to, an ActiveX control via associatedmethods. The interface of an ActiveX control is a set of methodsdefining certain input, output and behavior rules. Accordingly, acontainer application can invoke the methods of an ActiveX control toeffect the defined behavior and access the object data.

In addition to representing data stored by an ActiveX control,properties are used in formatting the display of an ActiveX control.Events are utilized to notify a container application of the occurrenceof an event, as well as to pass parameters relevant to the particularevent. For example, an ActiveX control is capable of informing itscontainer application of the occurrence of a selection event (e.g., whenthe user interface of the control has been “clicked on”).

ActiveX objects are typically implemented: (i) as in-process servers, or(ii) as out-of-process servers. In the former case the ActiveX controlis implemented as a Dynamic Link Library (“DLL”), and in the latter caseas an “executable”. ActiveX DLL's are loaded into the process space ofthe container application. As a consequence, data does not need to betransported between the container application and the ActiveX control.In contrast, ActiveX executables are loaded into a separate processspace from the container application. Since there is no shared memorybetween such applications, data is transported between ActiveX objectsand the container application. This is advantageous in the sense that anActiveX executable does not interfere with the processing of data in theclient application.

Although a number of programming environments exist for facilitatingdevelopment of Active X controls, as object-oriented constructs eachsuch ActiveX control operates independently of the containerapplication. That is, Active X controls are conventionally installed incontainer applications so as not to be affected by changes in parametersof the container application, and vice versa. Similarly, the occurrenceof ActiveX events does not automatically cause the execution of scriptsor the like in the container application. Although such relationshipsbetween the properties and events of an ActiveX control and a containerapplication could conceivably be established on an ad hoc basis, therehas not heretofore been a convenient mechanism for linking suchproperties and events with associated parameters of containerapplications.

SUMMARY OF THE INVENTION

Briefly, the present invention provides a system and method forestablishing associative relationships between properties of a containedobject and corresponding parameters of a container application. Thepresent system contemplates the establishment of both mutual andunilateral associative relationships, with a particular relationshipbeing specified via a user interface created upon instantiation of thecontained object. It is a feature of the present invention that suchassociative relationships may be established without modification of thecode comprising the contained object.

In one aspect the present invention facilitates implementation ofselected functionality of a container application prescribed by an eventscript. In an initial step an association is created between an eventarising within a contained object instantiated in a computingenvironment and a script associated with the container application. In apreferred implementation this association is recorded in an event sinkof a control site serving the container application. An event indicationis generated in response to occurrence of a particular event within thecontained object. In response, the event script is invoked and asequence of script commands corresponding to the selected functionalityare carried out.

In another aspect the present invention provides a system and method forcreating an association between a tag source of a container applicationand a property of a contained object. Specifically, an associativerelationship is defined between said tag source and the property, suchassociative relationship being determinative of the extent to whichchanges in the tag source and property will induce corresponding changesin the other. This associative relationship is recorded within aproperty sink of a control site for the container application, and maybe specified by a user upon instantiation of the contained object.Depending upon the nature of the tag source, various unilateral andmutual associative relationships may be established. For example, incertain instances a unilateral associative relationship may be specifiedsuch that changes in the tag source are reflected as correspondingchanges in the property, while changes in the property are not permittedto affect the tag source. In other cases the converse unilateralassociative relationship, or a mutual associative relationship, may alsobe specified.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings:

FIG. 1 is a block diagram of a computer system in which the presentinvention may be implemented.

FIG. 2 is a diagram of a dialog box for a bound object which has beeninstantiated in a container application in accordance with the presentinvention.

FIG. 3 provides a view of the dialog box of FIG. 2 in which the eventspage has been selected.

FIG. 4 provides a graphical representation of an instance of aninstalled object and the resulting control site established within awindow of a container application as a consequence of suchinstantiation.

FIG. 5 shows a block diagram of the structure of a property sinkincluded within the control site of FIG. 4.

FIG. 6 shows a block diagram of the structure of an event sink includedwithin the control site of FIG. 4

FIG. 7 shows a tag object of a type identified by a particular field ofthe property sink of FIG. 5.

FIG. 8 provides a block diagram of the structure of a property object ofthe type identified by a particular field of the property sink of FIG.5.

FIGS. 9 and 10 are respective flowchart representations of the manner inwhich changes in properties of a container application potentiallyinduce corresponding changes in tags of an instantiated object, and viceversa.

DETAILED DESCRIPTION OF THE INVENTION Overview

The present invention provides a generalized method for creatingassociations between parameters of programming objects, such as ActiveXcontrols, and associated parameters of a container application. That is,properties and events of ActiveX controls are respectively bound to datavariables (i.e., “tags”) and scripts of the container application. Thecontainer application could comprise, for example, industrial automationand control software having tags representative of the state of varioussensors or industrial processes. Scripts of the container applicationinclude a sequence of script commands for invoking functionality of thecontainer application, thereby allowing a user to specify how theapplication operates.

FIG. 1 is a block diagram of a computer system 100 in which the presentinvention may be implemented. The computer system 100 includes a userstation 102 that communicates with a system storage unit over network106. The system storage unit 104 comprises a direct access storagedevice, such as magnetic disk storage, in which data files are stored.The user station 102 includes a central processing unit (“CPU”) 108, adisplay 110, and a main memory 112. The CPU operates in response to usercommands, which it receives via a keyboard 114 or graphical user inputdevice 116. The user station 102 can communicate with one or more otheruser stations or a network server unit over the network 106.

The main memory 112 contains a variety of data structures andinformation, including an operating system, application programs,program objects, and user data. The main memory is represented as asingle entity, but those skilled in the art will appreciate that themain memory can comprise a combination of random access memory (“RAM”),hard disk drives, optical disk drives, and other storage devicescontaining logically segmented storage locations. The main memoryincludes a computer program containing a sequence of programinstructions whose execution implements the present invention.

The operating system contained in the memory 112 supports anobject-oriented programming environment for the execution ofobject-oriented programs, such as those written in, for example, the C++programming language. Accordingly, the memory contains program objectsthat are data structures of an object-oriented programming language.Application programs are invoked, or launched, by a user through thekeyboard 114 or graphical input device 116. The application programs canbe written in a variety of languages, including C++.

The display 110 comprises a display device such as a video terminal thatdisplays computer output and indicates system operations. Displayobjects can be pictured on the display and the user can designate dataoperations on the display by using the input device 116 or equivalentgraphical user input device.

In an exemplary implementation the computer system 100 may also sendcommands to, and receive data from, one or more industrial sensor orprocess control devices 120. The state of each such device 120 isreflected by the value of an associated tag, each of which may be aparameter of the container application. In the exemplary implementationthe container application comprises an industrial automation softwareprogram, such as the InTouch program module developed by WonderwareCorporation of Irvine, Calif. The Wonderware Intouch module includes atool kit for building screens and interfaces, and a graphical userinterface for monitoring and controlling the devices 120. For example,in the context of electrical distribution the software toolkit of theWonderware Intouch module enables rapid development of three dimensionalrepresentations of electrical distribution switchgear. The switchgearelevational representations have logical connections to the switchgeardevices. An elevation can be modified to any dimensions with anessentially infinite number of combinations and arrangements of metersand protection devices to quickly and accurately represent a customer'sswitchgear. In addition, a tabular representation of metering andsetup/set point information is generated automatically with theappropriate database server links established. The Wonderware Intouchmodule is disposed to provide similar representations and accompanyingdatabase links in other areas of industrial automation and control.

Display and Editing of Associative Relationships

FIG. 2 is a diagram of a dialog box 150 for a bound object which hasbeen instantiated in a container application as described hereinafter.In the exemplary implementation of FIG. 2, the bound object comprises anActiveX control identified as TextControl. When instantiated in acontainer application using conventional techniques, the dialog box 150could be expected to include the “Control Name”, “General”, “Colors” and“Fonts” pages. In accordance with the invention, a “properties” page isincluded to provide a mechanism for viewing and altering relationshipsbetween properties of the bound object (i.e., TextControl) andcorresponding tags of the container application. In addition, an“events” page serves to display the relationship between various eventsof the bound object and associated scripts of the container application.

Referring to FIG. 2, the properties page of TextControl reveals that theproperty BackColor is bound to the tag backgroundcolor of the containerapplication. The arrow graphic 152 indicates that a bidirectionalrelationship has been established between the property BackColor and theassociated tag backgroundcolor. That is, changes in the value of the tagbackgroundcolor will be reflected in the value of the propertyBackColor, and vice versa.

FIG. 2 also indicates that the property BottomTextLine is bound to thetag textline3 of the container application. The arrow graphic 154indicates that changes to the tag textline3 will result in correspondingchanges being made to the property BottomTextLine. The solid verticalline at the right edge of the arrow graphic 154 indicates that a userwill not be permitted to define the relationship between BottomTextLineand textline3 such that changes to the former induce correspondingchanges to the latter. This situation may arise when, for example, thetag textline3 is “read only”, or when there exists some other reason whyit is impermissible to bind the tag textline3 to the propertyBottomTextLine.

It is also seen that that the property ForeColor is bound to the tagtextcolor of the container application. The arrow graphic 156 indicatesthat changes to the tag textcolor will result in corresponding changesbeing made to the property ForeColor. The absence of a right-pointingarrow in arrow graphicl56 indicates that changes to ForeColor will notaffect the value of textcolor. Since a solid vertical line does notappear at the right edge of the arrow graphic 156, a user will bepermitted to allow changes in the property ForeColor to causecorresponding changes in the tag textcolor.

FIG. 2 further shows the property TextJustification to be bound to thetag tag1. However, the absence of any arrow graphic proximate thedisplayed name tag1 indicates that changes to the propertyTextJustification will not induce changes in the tag tag1, nor viceversa.

FIG. 3 provides a view of the dialog box 150 in which the events pagehas been selected. This view reveals that the event Click is bound tothe script ClickScript of the container application. In the exemplaryimplementation of FIG. 3 no further graphic representation is providedof the binding between the event Click and the property ClickScript.

Referring again to FIG. 2, the associations between the parameters ofthe bound objects and corresponding tags of the container applicationmay be modified by using the graphical input device 116 to change thestate of the applicable arrow graphic. For example, in a particularimplementation each arrow graphic will cycle between various permittedassociative states (e.g., unidirectional, bidirectional) in response torepeated selection by the device 116.

Establishment of Associative Relationships Between CorrespondingParameters

In a preferred embodiment, the binding between a container applicationand a bound object is implemented using the capability of the underlyingwindow system. The present invention is described assuming, forexemplary purposes and without limitation, that the underlying windowsystem is similar to the Microsoft Windows 3.1 operating system(“Windows”). Except as otherwise noted hereinafter, conventionaltechniques are utilized to install objects (e.g., an ActiveX control)within the Windows environment for subsequent binding to a containerapplication in accordance with the invention. Once an object has beeninstalled, the process of binding an object to a container applicationin accordance with the invention is initiated by instantiating theinstalled object in the container application.

In an exemplary embodiment the container application comprises anobject-oriented industrial automation program such as, for example, theInTouch program developed by Wonderware Corporation of Irvine, Calif. Inthis exemplary embodiment the container application creates windowswhich themselves function as containers for ActiveX control objects.After a control object has been placed in such a window and itsparameter associations have been selected via a dialog box (FIG. 2), thewindow may be saved and closed in response to commands provided to thecontainer application. A compiling operation is preferably invoked whenthe container window and contained control object are saved, therebycreating a “compiled window”. The container window and contained controlobject may then be generated from the compiled window during subsequentexecution of the container application.

Upon such placement of an installed object in a window of the containerapplication, a dialog box such as that shown in FIG. 2 is presented viadisplay 110. The desired associations between properties of theinstalled object and tags of the container object may then be selectedvia pointing device 116 so as to create a bound object. Once one or moreinstalled objects have been so bound to the container application, thewindow of the container may be compiled with the bound objects so as tocreate a “compiled window”. During execution of the containerapplication the compiled window is read and interpreted, which resultsin the creation of the bound object within the run-time environment. Ina preferred implementation the compiled window is stored as a file ofpredefined format, in which each object (e.g., shapes, wizard utilities,ActiveX controls) present within the window of the container applicationis represented as a block of data. Utilization of a particularpredefined format for the compiled window file is not necessary forimplementation of the present invention, and differing file formats forthe compiled window may offer advantages in particular applications.

FIG. 4 provides a graphical representation of an instance 160 of aninstalled object and the resulting control site 162 established within awindow 166 of a container application as a consequence of suchinstantiation. Those skilled in the art will appreciate that a standardcontrol site having certain well defined properties is generated uponplacement of an object such as an ActiveX control within a window of aWindows compatible container application. In accordance with theinvention, the control site 162 differs from such a standard controlsite in that sets of one or more property sinks 168 and event sinks 170are provided to facilitate the parameter associations depicted in FIGS.2 and 3. The control site 162 defines a standard interface 172 forcommunicating with the instantiated object 160 through a correspondingstandard interface 174 thereof.

Referring to FIG. 5, there is shown a block diagram of the structure ofa property sink 168 included within the control site 162. The propertysink 168 defines a tagname field 178 for identifying the name of the tagto be associated with the property object specified by the pointerwithin the field 180. An association field 182 specifies the type ofassociation (e.g., unidirectional) to be established between the tagobject and property object identified by the pointers within the fields184 and 180, respectively. In the exemplary case of FIG. 5, theassociation field 182 would specify a unidirectional relationshipbetween the tag object textcolor and the property objectTextJustification. The association field 182 registers any change in therelationship between a tag object and corresponding property objecteffected using the pointing device 116 in the manner described abovewith reference to FIG. 2.

FIG. 6 shows a block diagram of the structure of an event sink 185included within the control site 162. The event sink 185 defines aDISPID field 186 containing an identifier corresponding to a givenevent. In addition, a CString field 187 is provided for storing the nameof a script for the container application associated with the event. Thename in the CString field is provided to the container application inresponse to occurrence of the given event, which executes thecorresponding script.

Referring to FIG. 7, there is shown a tag object 190 of the typeidentified by field 184 of the property sink of FIG. 5. The tag object190 includes a tagname field 192, PTACC handle field 194, and statusflag field 196. The contents of the tagname field 192 will be identicalto the contents of the tagname field 178 included within the propertysink 168. In a preferred embodiment the PTACC handle field 194 providesa unique identifier for a particular tag. This identifier is returned bya dynamically linked library (“DLL”) named “PTACC” to requesting thirdparty applications.

FIG. 8 provides a block diagram of the structure of a property object200 of the type identified by field 180 of the property sink of FIG. 5.As is indicated by FIG. 8, the property object 200 includes a DISPIDfield 202 for identifying a particular parameter of the bound object(e.g., ActiveX control). In an exemplary implementation the industrystandard dispatch interface (“IDispatch”) of the bound object furnishesan index stored in the DISPID field in response to a call by thecontainer application for a method of the bound object. The containerapplication then calls an “Invoke” method of the object's dispatchinterface, which causes the object to retrieve the method associatedwith the index in the DISPID field 202. The desired method is thencalled by the bound object.

The property object 200 further defines a “CString” field 204 forstoring the name of the tag corresponding to the container propertyassociated with such tag. Also included within the property object 200is an “ASSOCTYPE” field 206 which records the type of associationbetween such container property and tag. In addition, a “COcxTag” field208 is provided for storing a pointer to an object wrapper surroundingmethods used by the container application to interface with tags. Theproperty object 200 also defines a “COcxProperty” field 212 for holdinga pointer to an object wrapper surrounding methods for changingproperties of the bound object.

Mapping Changes Between Corresponding Properties and Tags

When a compiled window (described above) is loaded during execution ofthe container application, the property sinks 168 and event sinks 170associated with the compiled window are regenerated and used to recordany change in the operative association between properties of boundobjects and corresponding tags of the container application. FIGS. 9 and10 are respective flowchart representations of the manner in whichchanges in such properties potentially induce corresponding changes insuch tags, and vice versa.

Referring to FIG. 9, in step 220 a property of a bound object is causedto change in state or value (i.e., a “property change”) and theassociated control site (FIG. 4) of the bound object is notified (step222). It is then determined whether the notification received at thecontrol site is with regard to a property change (step 224). If not, nofurther processing relating to a potential change in the value of anassociated container tag is performed (step 226). If the notificationcorresponds to a property change, it is attempted to identify theproperty sink (FIG. 5) corresponding to the property being changed (step228). If a corresponding property sink is not found (step 230), then nofurther processing is performed (step 232). In the case where acorresponding property sink is identified, an OnEvent member function iscalled (step 234). The OnEvent member function serves to convert theproperty change into a corresponding change in state or value of theassociated tag (i.e., a “tag change”).

In step 236, an operation is performed to validate the proposed tagchange arising from the property change. In a preferred implementationthis validation process entails determining whether the proposed tagchange is within a predefined range of valid tag values. If the proposedchange is not validated (step 238), no further processing is performed(step 240). In the case where the property change is validated, thecontainer application makes the corresponding validated change in theassociated tag (step 242).

Referring now to FIG. 10, in step 250 a tag change is experienced by atag monitored by the container application and a notification message isgenerated in response. In step 254 it is then determined whether thenotification message corresponds to an industry standard “DBCHANGE”message (i.e., a type of message which has been registered in theWindows environment to facilitate interpretation by a receivingapplication). If not, no further efforts are made to make a propertychange corresponding to the tag change (step 256). If the window messagecorresponds to a DBCHANGE message, it is attempted to identify theproperty sink (FIG. 5) associated with the tag experiencing a change(step 258). If an associated property sink is not found (step 260), thenno further processing is performed (step 262). In the case where acorresponding property sink is identified, an OnTagChange memberfunction is called (step 264). The OnTagChange member function serves toconvert the tag change into a corresponding property change.

In step 266, an operation is performed to validate the parametersreturned by the OnTagChange member function. In a preferredimplementation this validation process entails determining whether theproposed property change falls within a predefined range. If theproposed change is not validated, no further processing is performed(step 267). In the case where the property change is validated (step268), a pointer to the appropriate property object is retrieved from theassociated property sink (step 270). If the retrieved pointer is invalid(step 272), then no further processing is performed (step 274). If avalid pointer has been retrieved, then a corresponding change is made inthe associated property via an interface of the application program(step 276).

In a preferred implementation of the procedure set forth in FIG. 10,several object classes described in CODE SECTION I are invoked.Specifically, CtagServer and CocTag are classes disposed to “wrap”various methods for interfacing with the tags monitored by the containerapplication. Each “wrapper” instance of this class provides an interfacebetween the container application and any proprietary methods forinterfacing with such tags. The class CpropSink corresponds to aspecific implementation of a property sink. The class CocxProperty isdesigned to wrap properties of control objects and to store pointers(i.e., Idispatch) associated locations of such properties. The SetValuemember function uses the Idispatch pointer to change the value of acontrol object property associated with a tag experiencing acorresponding change. In CODE SECTION I, the “//” expression is used toidentifies comments to the code.

Code Section I

CTagServer

LRESULT CTagServer::WindowProc(UINT message, WPARAM wParam, LPARAM1Param) { if (message == m_DbChgMsg) { // interpret the 1Param as ahandle of a tag HPT hPt = (HPT) 1Param; // Get the tag associated withthis message. COcxTag* pTag = (COcxTag*) GetExtraLong(hPt, 0); if(!pTag) return false; // Get the sink associated with this tag.ITagChange* pSink = (ITagChange*) GetExtraLong(hPt, sizeof(LONG)); // ifthere is a sink call it else call tags virtual method. if (pSink)pSink−>OnTagChange(pTag); else pTag−>OnTagChange(NULL); return TRUE; }return CWnd::WindowProc(message, wParam, 1Param); } voidCPropSink::OnTagchange(COcxTag*) { // make sure there is a propertyobject associated with this tag // if not then initialize one if(!m_pProp) InitProperty(); // verify that there is a property, tag andthat the association between // the two indicates that the tag changesthe property (this relationship // is defined by the graphic on theproperty page when the association // is defined) if (m_bIgnoreChange ∥!m_pProp ∥ !m_pTag ∥ ((m_assocType != TAG_CHANGES_PROP) && (m_assocType!= BOTH))) return; // some flags here solve some timing problemsintended to solve // circular events. ie. Tag change property whichchanges tag which // changes property... m_bIgnoreChange = true;m_pProp−>SetValue(m_pTag−>GetValue()); m_bIgnoreChange = false;

Execution of Container Scripts in Response to Events

As is indicated by FIG. 3, the dialog box of a bound object representsany association existing between event occurrences in the object andscripts defined by the container application. In the exemplaryembodiment of FIG. 3, a user may alter such associations by performingediting operations upon the dialog box displayed by the events page.

In CODE SECTION II below, exemplary code is provided for effecting theassociation of event occurrences to the execution of container scriptscontemplated by the present invention. Specifically, CODE SECTION IIincludes the definition of a class “CScriptSink” disposed to facilitateimplementation of the event sinks described with reference to FIG. 6. Inparticular, CScriptSink causes event notification messages generated bythe bound object to be registered and sent to the container application.CODE SECTION II further includes definition of a class defined as“COcxItem”, which is responsible for creating control sites in responseto instantiation of bound objects as described above with reference toFIG. 4. Also defined is the member function “OnCmdMsg”, which isoperative to: (i) determine the type of an event notification which hasoccurred, (ii) locate the associated container script per therelationship defined in the applicable events page (e.g., FIG. 3), and(iii) cause execution of the associated script. Calls to the functionOnCmdMsg may be made in accordance with the standard COM protocol.

Code Section II

COcxItem

BOOL COcxItem::OnCmdMsg(UINT nID, int nCode, void* pExtra,AFX_CMDHANDLERINFO* pHandlerInfo) { AFX_EVENT* pEvent = (AFX_EVENT*)pExtra; if (nCode == CN_EVENT && !m_bDesignMode) { COcxSink* pSink =NULL; switch (pEvent−>m_eventKind) { case AFX_EVENT::event: { // get theevent sinks C String sText; pSink =m_EventSinks.GetItem(pEvent−>m_dispid); if (!pSink) return false; //create an event object COcxEvent event(pEvent, this); // Get the scriptname for the current event sText = pSink−>GetText(); // cause the scriptto execute pSink−>OnEvent(&event, sText); return true; } // // othercases here // } } return CWnd::OnCmdMsg(nID, nCode, pExtra,pHandlerlnfo); CScriptSink: void CScriptSink::OnEvent(COcxEvent* pEvent,CString szScriptName) { C String szComposed; C String szEventName; UINTdwParamCount; UINT dwIndex; C String szParamName; _variant_tvtParamValue; CEventTableUtil event; // essentially build up a structurethat holds the types // and values for the script to execute properlyszEventName = pEvent−>GetEventName(); dwParamCount =pEvent−>GetParamCount(); szComposed = szEventName; for (dwIndex=0;dwIndex < dwParamCount; dwIndex++) { szParamName =pEvent−>GetParamName(dwIndex); vtParamValue =pEvent−>GetParamValue(dwIndex); szComposed += szParamName;event.AddNamedVariant((LPCSTR)szComposed, vtParamValue); szComposed =szEventName; } // register the message wWizardCallMsg =RegisterWindowMessage(“InTouchWiZardCallMsg”); // send the registeredmessage over to the main application OesExecuteScript(m_sText,pEvent−>GetOcxInstanceName()); // clear out the table of parameterinformation event.ResetContent();

Although the above application has been described primarily in terms ofparticular implementations of techniques for creating associationsbetween contained objects and various parameters of containerapplications, one skilled in the art will be able to develop alternativeimplementations based upon the teachings herein. Thus the application ismeant only to be limited by the scope of the appended claims.

What is claimed is:
 1. A method for implementing selected functionalityof a container application configured to provide a visual interfacerepresentative of states of monitored parameters of an industrialprocess, said container application being operative within a computingenvironment, said method comprising: creating a persistent associationbetween an event arising within a contained object disposed tofacilitate provision of a visual indication of ones of said states of atleast one of said monitored parameters and a script associated with saidcontainer application; recording a persistent associative relationshipestablished between a parameter of said container application and aproperty of said contained object wherein the property relates toattributes of said contained object; generating an event indication inresponse to occurrence of said event within said contained object; andinvoking said script in response to said event indication, said scriptincluding a sequence of script commands corresponding to said selectedfunctionality.
 2. The method of claim 1 further including creating acontrol site associated with said container object within said computingenvironment, said control site including an event sink for recordingsaid association between said event and said script.
 3. The method ofclaim 2 further including providing a name associated with said scriptto said container application in response to receipt at said controlsite of said event indication.
 4. The method of claim 1 wherein saidcreating includes defining said persistent association prior to acompiling operation involving said container application and saidcontrol object, said compiling operation creating a compiled windowcontaining information relating to said persistent association.
 5. Themethod of claim 4 wherein said compiled window is loaded into saidcomputing environment upon execution of said container application.
 6. Asystem for implementing selected functionality of a containerapplication configured to provide a visual interface representative ofstates of monitored parameters of an industrial process, said containerapplication being operative within a computing environment, said systemcomprising: a user interface for facilitating creation of a persistentassociation between an event arising within a contained object disposedto facilitate provision of a visual indication of ones of said states ofat least one of said monitored parameters and a script associated withsaid container application, said user interface being employed to definesaid persistent association during instantiation of a control object insaid container application; means for recording a persistent associativerelationship established between a parameter of said containerapplication and a property of said contained object wherein the propertyrelates to attributes of said contained object; means for executing acompiling operation involving said container application and saidcontrol object subsequent to definition of said persistent association;means for generating an event indication in response to occurrence ofsaid event within said contained object; and means for invoking saidscript in response to said event indication, said script including asequence of script commands corresponding to said selectedfunctionality.
 7. The system of claim 6 wherein said means for invokingfurther includes a control site created upon instantiation of saidobject in said computing environment, said control site including anevent sink for recording said association between said event and saidscript.
 8. The system of claim 7 wherein said event sink includes afirst field for storing a representation of said event indication and asecond field for storing a string representative of a name of saidscript.
 9. The system of claim 6 wherein said compiling operation yieldsa compiled window, said compiled window being loaded into said computingenvironment upon execution of said container application.
 10. A systemfor implementing selected functionality of a container applicationconfigured to provide a visual interface representative of states ofmonitored parameters of an industrial process, said containerapplication being operative within a computing environment, said systemcomprising: an event sink in which is stored a persistent associationbetween an event arising within a contained object instantiated in saidcomputing environment and a script associated with said containerapplication wherein said persistent association is defined duringinstantiation of said contained object, said event sink generating anevent indication in response to occurrence of said event within saidcontained object wherein said contained object facilitates provision ofa visual indication of ones of said states of at least one of saidmonitored parameters; and a control site operative to invoke said scriptin response to said event indication, said script including a sequenceof script commands corresponding to said selected functionality whereinsaid control site is established within said container application as aconsequence of said instantiation of said contained object; and aproperty sink included within said control site, the property sinkrecording a persistent associative relationship established between aparameter of said container application and a property of said containedobject, wherein the property relates to attributes of said containedobject.
 11. The system of claim 10 wherein said event sink includes afirst field for storing a representation of said event indication and asecond field for storing a string representative of a name of saidscript.
 12. The system of claim 10 further including means forregenerating said event sink upon execution of said containerapplication in order to thereby create a regenerated event sink, saidregenerated event sink recording changes to said persistent association.13. A system for creating one or more persistent associations between acontainer application operative within a computing environment and acontained object within said computing environment, said containerapplication being configured to provide a visual interfacerepresentative of states of monitored parameters of an automatedindustrial process, said system comprising: a control site associatedwith said container application; and a property sink included withinsaid control site, said property sink recording a persistent associativerelationship established between a parameter of said containerapplication and a property of said contained object and said propertyrelates to attributes of said contained object; an event sink in whichis stored a persistent association between an event arising within saidcontained object and a script associated with said container applicationwherein said contained object facilitates provision of a visualindication of ones of said states of at least one of said monitoredparameters.
 14. The system of claim 13 wherein said associativerelationship is determinative of the extent to which changes in saidparameter and said property will induce corresponding changes in theother.
 15. The system of claim 13 wherein said associative relationshipdefines a unilateral associative relationship permitting changes in saidproperty to be reflected as corresponding changes in said parameter, butnot permitting changes in said parameter to be reflected ascorresponding changes in said property.
 16. The system of claim 13wherein said associative relationship defines a mutual associativerelationship permitting changes in said parameter to be reflected ascorresponding changes in said property, and vice versa.
 17. The systemof claim 13 wherein said associative relationship is defined byselecting one of a plurality of predefined associative relationships.18. The system of claim 13 further including means for regenerating saidproperty sink upon execution of said container application in order tothereby create a regenerated property sink, said regenerated propertysink recording changes to said persistent associative relationship. 19.The system of claim 18 further including means for regenerating saidevent sink upon execution of said container application in order tothereby create a regenerated event sink, said regenerated event sinkrecording changes to said persistent association.